In some computer programs, multiple program threads may execute concurrently on a single system and may access shared memory locations. The interleaved execution of such threads in shared-memory, multi-threaded computing environments may cause one or more of the threads to execute incorrectly. For example, if two threads in a banking application are each configured to execute a withdrawal by first checking for sufficient account balance and then making the withdrawal, then incorrect interleaved execution may result if, for instance, both threads perform the account balance check before either thread withdraws the money, resulting in a negative account balance. Thus, interleaved execution of the two threads may result in incorrect program behavior, commonly known as race conditions, which must be avoided.
Programmers of concurrent systems must take care to avoid inopportune interleavings of concurrent operations. To ensure correctness, programmers often rely on various concurrency control mechanisms, such as synchronization locks. A lock is a software or hardware construct associated with one or more memory locations. In some lock implementations, a thread must hold a lock associated with a given memory location before it may read from and/or write to that location.
Transactional memory is a concurrent programming paradigm that may allow a programmer to designate a section of code as atomic. A transactional memory implementation then ensures, via underlying software and/or hardware mechanisms, that such critical sections are executed atomically (i.e., all at once) with respect to other threads in the system. For instance, in the banking example above, a programmer may designate that the account balance check and the withdrawal operation should be executed together atomically with respect to other threads. Thus, by forbidding the interleaved execution described above, the race condition may be obviated. Transactional memory may be implemented in hardware, software, or a combination thereof.